Digital content has gained wide acceptance in the public. Such content includes, but is not limited to: movies, videos, music, and the like. Consequently, many consumers and businesses employ various digital media devices or systems that enable the reception of such digital multimedia content via several different communication channels (e.g., a wireless link, such as a satellite link, or a wired link, such as a cable connection). Similarly, the communication channel may also be a telephony based connection, such as DSL and the like. Regardless of the type of channel, the digital content and/or the distribution of the digital content is typically secured using a conditional access (CA) mechanism and a digital rights management (DRM) mechanism (e.g., encryption/decryption using keys).
Presently, specifications are being developed with respect to expanding the ways that content and services can be distributed over wireless communication networks. One such set of standards is being developed by the Open Mobile Alliance (OMA). In the OMA DRM system, for example, digital content (e.g., a movie or song) is associated with a rights object (RO). The RO provides granting rights to a Client Device for viewing or otherwise consuming the digital content. The entity in the Client Device that manages permissions and corresponding constraints relative to use of the digital content is commonly denoted as a DRM Agent. Nominally, a DRM Agent obtains an RO from a rights issuer (RI). DRM Agents conformant to the new OMA Secure Content Exchange (SCE) specifications (as well as to the legacy OMA DRM v2.x (i.e. OMA DRM v2.0 or OMA DRM v2.1) system) are intended to have the opportunity to participate in rights transfers with other such DRM Agents. In the legacy OMA DRM v2.x system, a domain is associated with and managed by a single RI, which implies that each DRM Agent needs to register with each RI for which it wants to make successful use of Domain ROs generated by that RI.
The conventional DRM rules regarding move RO transactions have several drawbacks. In particular, a special-purpose protocol is often implemented and runs that layer's security on top of an agent to agent (A2A) move RO transaction. In this case, the recipient device often cannot make a priori arrangements with the LRM, since consumption of ROs designated as requiring authorization require such authorization for each RO. Thus, this type of move RO transaction is no longer truly an A2A transaction. Additionally, although an outbound move (without local consumption) of the RO by a device that did not receive authorization from the LRM for that RO is allowed, once the device requests such authorization, the RO cannot be moved (or consumed) unless the device receives a corresponding authorization response from the LRM that indicates success. Further, the protocol is not equipped to handle a move of partial rights whereby the source device of the A2A move retains a partial state of an RO that could result in a subsequent move corresponding to the same RO. In addition, the protocol is inconsistent with moves of the RO via an RI without incurring substantial additional complexity within both the authorization protocol and the move via RI protocol to enable direct or indirect authenticated communications between LRMs and RIs. This would need to be done without sacrificing with the backwards compatible feature whereby an RI can deliver ROs to a legacy (i.e. OMA DRM v2.0/v2.1-only) device based on a prior successful move via RI request (that designates the intended recipient device) to that RI by an SCE-conformant source device.
Change request 429 to OMA DRM v2.0/v2.1 provided a procedure for a device that receives an RO within an RO acquisition protocol (ROAP) response directly from an RI to ascertain current revocation information concerning that particular RI in order to determine the fitness of that RI to provide ROs. This is done by means of online certificate status protocol (OCSP) messaging. In the change request, the only entities that generate ROs are RIs, which can be restricted to operating within a back-end service provider environment with its attendant physical security, personnel security, and audit controls. The introduction of the LRM into the SCE enabler implies that this nominally home-based entity needs to be truly revocable in a way that goes beyond just an initial device (that receives the RO directly from the LRM) making use of revocation information. This is true because besides the addition of this home-based entity type there is also the addition of further procedures to reuse ROs across multiple Devices.
In OMA DRM v2.0/v2.1, the only specified reuse of ROs across multiple devices pertains to domains of devices. A trust authority should allow the use of such domains only if the necessary contractual arrangements are in place, since RIs self-manage their domains. An LRM self-manages OMA DRM v2.x domains and/or directly generates OMA DRM v2.x domain ROs and/or Device ROs that are usable by compliant v2.x Devices only if it has been entrusted with a private key corresponding to a certificate with a rightsIssuer key purpose that makes it appear indistinguishable from an RI to v2.x Devices. All OMA SCE-conformant Devices (unlike OMA DRM v2.0/v2.1-only Devices) are required to support DRM time, which is advantageous in determining the current validity of certificate revocation lists (CRLs) and/or OCSP responses. Thus, these digitally signed objects can be “virally” spread and independently verified without relying on trust in the immediate source or the use of nonces to determine freshness. The “viral” aspect is important in that there is not a reliance on every device being compliant and thus providing the latest revocation information it has to other devices.